Red Hat Enterprise Linux (RHEL)

I guess to give it more context, my first job in the Linux ecosystem was in web hosting. And that was basically a Cintas shop and it was all run extremely lean and very bootstrappy do it on your own. You don't get any support. And for that environment, it was kind of just the way it is. It's very cutthroat. You have to move super fast. Once I moved over to the corporate side, every company I've worked with has been on rail. And the thing that really kind of makes it the best choice compared to using another operating system, another flavor of Linux and just kind of figuring out your own is the amount of support that Red Hat gives rail as far as extra tools like Satellite Insights and what's coming up now with Ansible and especially Ansible. Lightspeed, but also SLAs and stuff like that. Because yeah, I mean it was good learning in that first environment because there were no tickets, there was no support. It was figured out. But nowadays it's just nice to have an SLA agreement. I can just open a ticket. I say that that's something that does really well, but I also want to see it expanded, just more like vendor support at an enterprise level. I'm not sure yet what that would mean. I just have that every time we come up for renewal, I look at the price tag and it's like, what else can we do here? I like what Red Hat is doing just more.

Where it's very well suited is just if you're rolling out systems quickly, web front ends, and so forth. I think it's really well suited for that. Even backend operations. It does a good job. However, I do think that it's not as industrial-proven as other operating systems out there. Like say the banking industry, they love AIX, cause it's IBM, it's been around forever and it's rock solid. And to try to get that much computing power in an intel box is difficult. So RHEL is limited in what it can do versus some of the P series and I series stuff that IBM does.

Like I said before, with the automation environment RHEL is well suited to run the Ansible Navigator and the Ansible execution environment builder. So we can create our execution environment on RHEL natively instead of having to figure out how we do it as Ubuntu or other platforms.

It's well suited for installing pretty much anywhere and it's usually the documentation is very good and there's a lot of support from the documentation and training to make good use of the product. It's not as good as a workstation, it's better as a server product. It's not necessarily good in kind of other situations as well because of some of the licensing constraints.

Stability and performance are top-notch and if any issues are encountered their support is also excellent

Critical production environments are the best for RHEL case as the product ensures the security, stability and it is backed by the world class support that the most of the companies (and their shareholders) would appreciate.
It might not be too suitable for the startups or even some Dev teams within large enterprises, depending on their internal culture and practices. Though things definitely improved over the last few years and there is no strong case for the teams not to use RHEL nowadays.

Stable and support are great.

Stable operating system. Easy to support at scale

Well suited for those who are network savvy. And for those who like CLIs.

Workloads on public cloud where customers require reliability and supportability for applications and targeted hardware for multiple years.

A strong, reliable system for web site and web application hosting.

We use RHEL because it gives us security when setting up our services. We try to standardize our DC and work as much as possible with RHEL due to its ease of use, its support and the information that is found is very useful when running into a problem. I'm happy using RHEL.

Installing and configuring RHEL has been an ease to learn and execute. Most of the applications that I run requires linux or unix, which RHEL is my companies choice because of it reputation and the resources it provides.

RHEL is well-suited for applications where stability and security are critical, as well as where the ability to scale it and still manage efficiently is crucial.

It is less well-suited for environments where there are individual, specific requirements, where newer versions of libraries and applications are required, and particularly in migration of legacy .Net applications.

I think based on experience the stability the ease of patching and troubleshooting it is suitable for any application development. Less suitable when it involves integration with other windows servers for implementations such as SQL or other instances since the configuration seems complicated for most Windows users, command line most of the time is intimidating.

Multitasking, SSH, etc

We have a combination of Windows and Linux in our organization. The Windows systems are to provide support to the RHEL systems, such as Active Directory, File/Print servers etc. We've been replacing as many of the Windows systems with RHEL as we can due to the fact RHEL is just easier to manage, it's more stable, and it's far easier to automate. We fight with automation on Windows and configuration drift on Windows is a challenge. We don't have these issues with RHEL, and using ansible on RHEL is just inherent.

All our Linux solution is based upon RHEL since a simple webserver to a structured Cluster solution, including OracleRAC, VCS. We're starting to use container - Docker and OpenShift as well. TACACS+ solution for router/switches authentication works perfectly. Now for improvement the OracleRAC under RHEL works fine but I don't know if this is a Oracle strategy to sell their own Linux distribution but, some oraclerac modules fails sometimes running in RHEL.

This is highly recommended to support servers to transactional applications.

RHEL is excellent for the usage of Operating systems where a high available Linux is needed and the following features are needed: - High available Linux and configurations in the cluster - Patching cycles for vulnerabilities is needed on an ongoing basis and also configuration management with Red Hat Satellite - Support within 7x24. - Integration using automation of a high amount of servers needs to be accomplished. For example, using Ansible

Red Hat [Enterprise]Linux is well suited for web applications and it is less virus prone compared to other operating systems. Red Hat [HEL] is less suited for Desktops and users. The deployment and patching of the OS need to be looked at and must be improved. Licensing of Red Hat is fairly simple.

[ Red Hat Enterprise Linux] (RHEL) is a great suite for almost everything Linux and has a great ecosystem free Open Source of third party repositories to find what is not provided by default. ... an environment where 24x7 support is required, their support level is awesome, environments with a lot of vendor dependent applications, since almost all of them build their apps for [ Red Hat Enterprise Linux] (RHEL). [ Red Hat Enterprise Linux] (RHEL) could improve: SAP environments, I've compared its integration levels to other Linux vendors and it could be better. Mainframe (390) solutions. Although [ Red Hat Enterprise Linux] (RHEL) support for System Z is great, I believe SUSE's is better.

RHEL's stability is a good fit to host mission-critical applications/databases. Storage is easy to scale up and easy to work with Oracle ASM.

If you're running Linux in the enterprise, Red Hat should be your first choice. It's well-supported and third-party products for Linux will be designed to work with Red Hat. They may behave differently and less stably under other Linux operating systems—McAfee, I'm looking at you here! If the question is "Will x work with this flavor of Linux?", with Red Hat, the answer is always a Yes.

All servers work great. It is reliable, fast and secure. But it's not as intuitive as it could be for desktop use, a better GUI would help this. So far, we have not found an application that this will not work for.